Columbia Kermit/kermit.zip/newsgroups/misc.19971216-19980424/000140_news@newsmaster….columbia.edu _Sat Jan 31 00:53:25 1998.msg

Internet Message Format | 2020-01-01 | 6KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id AAA24621
    for <[e-mail]>; Sat, 31 Jan 1998 00:53:25 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA26439
    for kermit.misc@watsun; Sat, 31 Jan 1998 00:53:24 -0500 (EST)
Newsgroups: comp.protocols.kermit.misc
Path: news.columbia.edu!sol.ctr.columbia.edu!gondor!newshub.sdsu.edu!news.sgi.com!nntprelay.mathworks.com!howland.erols.net!ix.netcom.com!gerlach
From: [e-mail] (Matthew H. Gerlach)
Subject: Re: Expect and Kermit (was: Re: frequent timeouts!)
Message-ID: <[e-mail]>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <6ao98e$p4h$[e-mail]> <[e-mail]> <6aonud$42r$[e-mail]>
Date: Thu, 29 Jan 1998 16:50:33 GMT
Lines: 84
Sender: [e-mail]
Xref: news.columbia.edu comp.protocols.kermit.misc:8323

In article <6aonud$42r$[e-mail]> [e-mail] (Frank da Cruz) writes:
>In article <[e-mail]>,
>Matthew H. Gerlach <[e-mail]> wrote:
>: The kermit scripting language is a greate thing, most notably the fact
>: that kermit scripts will run on many platforms.  That being said I find
>: it very beneficial to control C-Kermit from Expect, and I work for a company
>: that does a lot of it.  The main benefit is that one might need to write
>: a script that controls many serial connections in conjuction with
>: many connections to regular UNIX programs.  This appears to be easier with
>: Expect.
>:
>Some concrete examples might be instructive.

Since I am a consultant for the company I mention above, I can't show code,
but I will try to explain what they do.  In short they have a UNIX box
that performs automated telephony testing.  This testing involves two
separate pieces.  One piece controls the end user's telephony equipment
via a serial port.  The other piece is the actual voice frequency testing
involved with DSP's.  The interface to voice frequency testing is an
interactive program.  So the scripts usualy send some commands to the
telephone equipment, and once it is all set up, some commands get sent
to the voice testing program.  So the Expect scripts coordinates the serial
stuff with the DSP stuff.

At this point it is probably worth noting, that the company I mention was
too cheap to pay for kermit to put on released product; so it "talks" to cu.
However, in house we tend to use kermit, because it's easier to use and has
the wonderful "log session" feature.  I use kermit exclusively just because
it is a great piece of software that is also well documented. I own copies
of both revs of the book.

>: Furthermore, Tk/Expect allows one to easily put a "pretty face"
>: gui on said script.
>:
>One ought to be able to do that anyway.  Code the user interface in Tk/Expect
>or whatever, and the real stuff in the Kermit script.  Keeps the bosses happy
>by looking pretty, and keeps the rest of us happy by working well :-)
>
>: In conclusion there are problems best solved by kermit scripts and problems
>: best solved using Expect and there are even more problems best suited to
>: Perl, which I prefer.  Use the best tool to solve the problem.
>:
>Agreed, provided it works.  If Kermit doesn't work with expect (I'm not
>saying it doesn't), then the best tool is Kermit without expect.  Given the
>amount of resources we have, there is a limit to the number of combinations
>we can support.  But of course, that's where this newsgroup comes in handy.
>
>Meanwhile, I think this is a useful dialog.  If my understanding of the
>Expect approach is correct, it is basically a screen-scraper, looking for
>the Kermit prompt, feeding commands to it, parsing the results, and so on
>in a loop of some kind until the desired result is achieved.  But Kermit's
>language includes a lot of features that don't fit this model, such as
>FOR and WHILE loops, SWITCH statements, IF-ELSE constructions, even GOTOs.
>I suppose these might be simulated at a "higher level", but isn't that
>pushing the model a bit?  Also, note that every Kermit command returns a
>status that can be tested by IF SUCCESS (or IF FAILURE); how do you do that
>with Expect?
>

Yes this is a very useful dialog, because we are discussing interesting
ways to use kermit :)  As you say Expect is basically a screen-scaper.
For those who are interested, Expect is an extension to the TCL scripting
language.  The Expect extention simply spawns the desired program and
opens a pseudo-tty to the STDIN/STDOUT of the child, in this case Kermit.
The TCL scripting language does have the usual IF-ELSE, FOR and WHILE,
subroutines and stuff.  The expect command itself looks an awful lot like
the use of minput followed by a switch.  As you point, however,
the kermit commands return a status that can be tested by
IF SUCCESS/FAILURE.  This information does not appear to be available to
Expect unless there is a kermit command like "print status of last command".
Is that a feature request?

As you point out above, there are cases when one should program the "real"
stuff in kermit and glue it to a user interface or whatever else needs gluing.

At this point I would like by throwing out yet another scripting
language, Perl.  One can do the same thing in Perl as one does with
Expect, and that is what I personally do because I find Perl to be
a much more powerful programming language.  Another interesting point
is that a common question to the perl news group is "how do I control
a serial port from perl"?  Well, I always tell them, have Perl "talk"
to kermit!  I think now I will tell them, have perl talk to kermit scripts.

Matthew H. Gerlach